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Abstract 


This document is an Internet Architecture Board (IAB) report on the 
role of the Internet Research Task Force (IRTF), both on its own and 


in relationship to the IETF. This document evolved from a discussion 
within the IAB as part of a process of appointing a new chair of the 
IRTF. 
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Iz 


Introduction 


As part of the process of appointing a new chair of the Internet 
Research Task Force (IRTF), the IAB considered the future role of the 
IRTF both on its own and in relationship to the IETF. The IAB has 
expanded this discussion into this IAB report on the role of the 
IRTF, and circulated this document for wider community review. (As 
one result of this discussion, Aaron Falk was appointed the new chair 
of the IRTF in March 2005.) 


The Relationship between the IRTF, the IAB, and the IETF 


Before 1989, the IAB (then called the Internet Activities Board) 
oversaw a number of task forces. In 1989, organizational changes 
were made to coalesce these task forces into two groups, the IETF and 
the IRTF. The IRTF was tasked to consider long-term research 
problems in the Internet, and the IETF was to concentrate on short- 
to medium-term engineering issues related to the Internet. At this 
time, all of the task forces except the IETF were restructured as 
IRTF research groups. For example, the End-to-End Task Force became 
the IRTF’s End-to-End Research Group (E2ERG) and the Privacy & 
Security Task Force became the IRTF’s Privacy & Security Research 
Group (PSRG) [IABWebPages] [RFC3160] [E2ERG]. 


Much of the early participation in the IETF as well as in the IRTF 
was from the academic and research communities. (We don’t have a 
citation from this, but a look at the members of the IAB from the 
1980’s and early 1990’s shows IAB members from institutions such as 
MIT, UCLA, BBN, UCL, SDSC, and the like, while IAB members from the 
last few years were more likely to list their organizations at the 
time of service as Cisco, IBM, Microsoft, Nokia, Qualcomm, and 
Verisign [IABWebPages]. We expect that a study of authors of RFCs 
would show a similar trend over time, with fewer authors from the 
academic and research communities, and more authors from the 
commercial world.) While the IRTF has continued to have significant 
participation from the academic and research communities, the IETF 
has focused on standards development and has become dominated by the 
needs of the commercial sector. 


The IRTF has generally focused on investigation into areas that are 
not considered sufficiently mature for IETF standardization, as well 
as investigation of areas that are not specifically the subject of 
standardization, but could guide future standards efforts. 


The IRTF Research Groups guidelines and procedures are described in 
RFC 2014. The IRTF Chair is appointed by the Internet Architecture 
Board (IAB), and charters IRTF research groups (RGs) in consultation 
with the Internet Research Steering Group (IRSG) and with approval of 
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the IAB. The chairs of the RGs comprise the main part of the IRSG, 
although the IRTF Chair can also appoint at-large members to the 
IRSG. 


As RFC 2014 states, the IRTF does not set standards. While 
technologies developed in an RG can be brought to the IETF for 
possible standardization, "Research Group input carries no more 
weight than other community input, and goes through the same 
standards setting process as any other proposal" [RFC2014] (Section 
1.1). This is necessary to ensure that RGs don’t become a part of 
the standards process itself. 


RFC 2014 continues to say that "since the products are research 
results, not Internet standards, consensus of the group is not 
required" [RFC2014] (Section 3). However, the NameSpace Research 
Group was one RG that did require consensus decisions; this group was 
chartered exclusively to make a recommendation to the IETF. 


RFC 2014 goes on to describe Research Group operation, meeting 
management, staff roles, group documents, and the like. This 
document is not a revision of RFC 2014, but instead a more wide- 
ranging discussion of the possible roles of the IRTF. 


The past history of IRTF Chairs is as follows: Dave Clark 
(1989-1992); Jon Postel (1992-1995); Abel Weinrib (1995-1999); Erik 
Huizer (1999-2001); Vern Paxson (2001-2005). 


2.1. Differences between IRTF and IETF Groups 


Two key differences between IRTF research groups and IETF working 
groups are that IRTF groups are not trying to produce standards of 
any kind and that the output of IRTF groups does not require 
consensus within the RG, or broad consensus from the IETF. 


In some cases, IRTF groups have acted as research groups with minimal 
constraints, creating a community for discussing research proposals, 
with mature proposals "tossed over the fence" to an IETF group for 
standardization. The Reliable Multicast Research Group (RMRG) was an 
example of such a group, with standardization efforts in the Reliable 
Multicast Transport working group (RMT). 


2.2. Research Groups as Non-blocking Entities 


As stated in RFC 2014, the IRTF does not set standards. It is 
important that, unless clearly specified otherwise by the IESG, 
research groups do not act as gateways controlling the advancement of 
standards, experimental RFCs, or informational RFCs produced by 
working groups in the IETF. 
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Similarly, as stated in RFC 2014, existing research groups also do 
not necessarily prevent the creation of new research groups in 
related areas. Of course, when considering a proposal for a new 
research group, it is perfectly appropriate for the IRTF and the IAB 
to consider the relationship with existing research groups. However, 
"multiple Research Groups working in the same general area may be 
formed if appropriate" [RFC2014] (Sections 1.1 and 2.1). 


3. The Range of IRTF Groups 


There is a wide range of ways that IRTF groups can currently be 
structured. Some of the most significant are: 


* Membership: Groups might be open or closed (in terms of 
membership). The End-to-End Research Group and the NameSpace 
Research Group are both past examples of closed RGs. 


* Timescale: While RGs are generally long-term, groups could be 
either long-term (ongoing) or short-term with a specific goal; the 
NameSpace Research Group is an example of an RG that was chartered 
as a short-lived group [NSRG]. We note that RFC 2014, written in 
1996, assumed that RGs would be long-term: "Research Groups are 
expected to have the stable long term membership needed to promote 
the development of research collaboration and teamwork in exploring 
research issues" [RFC2014] (Section 1). 


* Relationship to IETF: Groups can include a goal of producing 
proposals to be considered in the IETF (e.g., the Anti-Spam 
Research Group) or can be independent of any current or proposed 
work in the IETF (e.g., the Delay-Tolerant Networking Research 
Group). 


* Range of activities: IRTF activities could consist not only of 
research groups and their associated meetings, workshops, and other 
activities, but also of separate workshops or other one-time 
activities organized directly by the IRTF. To date, however, the 
IRTF has not organized such activities other than in the form of 
BOFs at IETF meetings. 


* Both research and development: IRTF groups can focus on traditional 
research activities, but they could also focus on development, on 
tool-building, on operational testing or protocol interoperability 
testing, or on other activities that don’t fit the framework of a 
working group (WG). Instead of having a specific plan for the 
evolution of the IRTF, we think that this will have to be explored 
over time, with discussions between the IRTF Chair, the IRSG, and 
the IAB (and with the IESG as appropriate). 
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As discussed above, the IAB believes that the range of research 
groups could be expanded further, in terms of timescale, relationship 
to the IETF, range of activities, and range between research and 
development. 


4. Issues for the Future 


This section discusses some of the issues in the future evolution of 
the IRTF. A key issue, discussed in Section 4.1 below, concerns how 
the IRTF can best contribute on questions of network architecture. 


Similar issues could be raised in how the IRTF can best contribute to 
incubating technology for later development in the IETF. We 
emphasize that we are not proposing that the IRTF should become a de 
facto holding point for technologies that are not making clear 
progress in the WGs. Some technologies might not make progress in 
WGs because of key open issues, making an RG an appropriate step. 


Other technologies, however, might not make progress in WGs because 
of a lack of interest, inherent design weaknesses, or some other 
reason that does not justify moving it into an RG instead. 


4.1. IRTF Groups and Network Architecture 


One interest of the IAB is how progress is made on issues of network 
architecture. This includes help in developing and evaluating new 
architectures, and in understanding the evolving architecture and 
architectural issues of the decentralized, deployed Internet 
infrastructure. This also includes developing tools that could be 
used in the above tasks. 


The spectrum of potential activities for IRTF groups ranges from the 
visionary to the specific, including the following: 


* Architecture: Where are we, and where do we go from here? 


* Incubation: We think we know where to go, but we don’t yet have 
the tools to get there. 


* Problem focus: We have some specific problems to solve or potential 
solutions to evaluate. 


Some RGs have addressed broad architectural issues, with a mixed set 
of results; examples of such RGs include the End-to-End Research 
Group, the NameSpace Research Group, and the Routing Research Group. 
For other RGs (e.g., the Host Identity Protocol Research Group), the 
focus of the group is to study a specific proposal, with wider 
architectural issues raised at workshops held by the RG. Finally, 
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some RGs are in specific areas with well-defined boundaries, with 
topics that don’t have broad impact on the wider Internet 
architecture. 


Where an IRTF RG lies on the spectrum of possible activities depends 
in part on where the IETF and the field itself lie. For example, in 
areas such as network management where the IETF community has doubts 
or concerns about where we should be going with management 
technology, it would be useful for the IETF to be able to look to the 
IRTF for architectural evaluation. In contrast, in areas where the 
architectural approach is better established, an RG with an 
incubation approach might be more appropriate. Finally, where many 
pieces of the puzzle are in place, but some significant problems 
remain, an RG with a problem focus might make sense. 


For those RGs with an architectural focus, it would not be 
appropriate for the IAB to charter an RG to come up with *the* 
architectural perspective on some topic; any such result would 
necessarily have to pass through the wide feedback and consensus 
procedures of the IETF. However, it is appropriate for the IAB to 
ask an RG for exploration and discussion of an architectural issue; 
e.g., the IAB has asked the Routing Research Group for feedback about 
research objectives for inter-domain routing improvements 
[IABMinutes]. It is also possible for RGs to make recommendations on 
architectural or other issues, with or without the request of the 
TAB; e.g., the End-to-End Research Group [RFC2309] and the Crypto 
Forum Research Group have both made recommendations to the general 
IETF community. However, some RGs function better as a breeding 
ground for ideas, and not as a consensus-—building community. For 
example, while the NameSpace Research Group was "an invitational 
research group chartered exclusively to make a recommendation to the 
IETF" [NSRG], the group never achieved a clear consensus. 


While the IAB doesn’t have clear answers on the evolving role of the 
IRTF in addressing and understanding open architectural issues, this 
is an area that will be explored in the upcoming years, in 
collaboration with the IRTF Chair. One of the goals of the IAB is to 
make more use of the IRTF in investigating architectural issues. 


4.2. The Relationship between the IETF and the IRTF 


Another area that could use more attention is making the relationship 
between the IETF and the IRTF more productive. For many (though not 
all) of the research groups in the IRTF, part of the power of the RG 
lies in its relationship to the IETF. Of current and recent RGs, for 
example, this is true of the Anti-Spam (ASRG), the Crypto Forum 
(CFRG), Host Identity Protocol (HIP), and a number of others. 
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The interchange between the IETF and the IRTF could be improved in 
both directions: from the IETF to the IRTF in terms of information 
about IETF problems that could be helped by further research and 
development, and IETF evaluation of RG efforts and direction; and 
from the IRTF to the IETF in terms of reports, documents, proposals, 
BOFs, and the like. Current paths for this interchange include IRTF 
reports at IETF plenary meetings; RG meetings before or after the 
IETF, or in one of the scheduled sessions during the IETF; workshops; 
and IRTF documents. 


One possibility (for some research groups, not for all of them) could 
be for an RG to have a design-team-like relationship to the IETF or 
to an IETF working group, with an RG charter that includes an 
agreement of deliverables, with some notion of the time frame for 
those deliverables. An issue that would need to be resolved here is 
when is it appropriate for an RG to undertake such a relationship vs. 
an IETF WG doing it directly, as is sometimes already done. 


We note that as in WGs, RGs are composed of volunteers who make their 
own choices of research and engineering topics. RGs are usually 
started by a proposal from individuals who want to form the RG. 

Thus, it is important to realize that IRTF activity often will not be 
viable in the absence of individuals who would like to take on the 
particular work, and this tempers the usefulness of IETF WGs 
providing input to the IRTF regarding desired IRTF directions or 
activities. For example, while the IETF can request specific 
research activities from IRTF RGs, results will require individuals 
within the RGs willing to undertake this work. 


IRTF RGs have been of significant benefit to the IETF; a number of 
IETF proposals began as discussions in the End-to-End Research Group, 
for example. At the same time, the interchange with RGs can take 
significant time and effort from WG chairs and from ADs, sometimes 
with little to show for it if the RG’s direction is at odds with that 
desired by the WG chairs or ADs. One task for the future is to 
improve the dialogue between the IETF and the IRTF while not 
increasing the load on WG chairs and ADs. 


One role of the IRTF could be to open some new communication paths 
between the research community and the IETF. Over the last ten 
years, as the Internet has grown and matured, and the difficulties of 
making changes to the Internet architecture have increased, the 
research community’s participation in the IETF has dropped. We are 
not necessarily expecting to reverse this trend, but it would be good 
for the output of the research community to reach the IETF somewhat 
more than it does now, and for the research community to hear more 
from the IETF. 
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We would like to shape an IRTF that meets the needs of researchers in 
this domain, providing interaction both with other researchers and 
with other industry technologists. In this respect, we would like to 
see an IRTF that has momentum that is self-sustaining from voluntary 
efforts, that undertakes (some) work on topics that align to the 
interests of the IETF, and in such a fashion continues to be of 
material assistance to the IETF standardization effort. We would 
also like to see an IRTF that continues to give thoughtful 
consideration and input to the development of the Internet 
architecture. 


4.3. Relationships between the Research and Development Communities 


One of the current and future roles played by the IRTF is that of a 
bridge between the research and development communities; the research 
community in general is less of an active force in the IETF than it 
was in the beginning of the IETF’s history. At the risk of resorting 
to stereotypes, IETFers sometimes view the network research community 
as irrelevant or disconnected from reality, while researchers 
sometimes view the IETF as insufficiently thoughtful or as an 
unproductive place for investing one’s research energies. There is 
also a natural difference in timescales, with the IETF more focused 
on near- to medium-term issues, and researchers often more focused on 
longer-term issues. 


Unfortunately, disconnections between the research and development 


communities can hurt both the research and the development. Just as 
one example, from "Failure to Thrive: QoS and the Culture of 
Operational Networking" [B03]: "Remarkable intelligence and energy 


have been lavished upon the architectural design of QoS, but much 
less attention has been devoted to careful analysis of the relevant 
problem space from an operational or economic perspective. This 
discrepancy is symptomatic of a broken (or attenuated) feedback loop 
between network operations and research." Thus, one potential role 
of the IRTF is to help provide a productive forum that improves the 
communication in both directions between the two communities. 


4.3.1. What’s in a Name: On the Name ‘Research Group’ 


There have been proposals that for some groups the name "Research 
Group" is incorrect or unnecessarily off-putting to some potential 
participants and that other names such as "Architecture Group" might 
in some cases be more useful. Such a terminology change is 
potentially quite significant, and needs to be evaluated in terms of 
the IAB’s overall role and responsibility for guiding the development 
of architectural considerations within the IETF. Another issue is 
that different RGs have different mixes of people, in terms of 
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researchers from academia, industry practitioners, and IETF WG 
participants; it is not clear how changing the names would affect 
this. 


4.4. The RFC Track for IRTF Documents 


Currently, RFCs produced by RGs are published as individual 
submissions, under the review of the RFC Editor [RFC3932]. There is 
currently a discussion (and pending Internet-Draft) about the need 
for a venue for publishing RG output that is clearly marked as 
research, as opposed to the output of an IETF WG. This is both to 
more clearly distinguish RG output from standards documents of the 
IETF and to give RG output more visibility than that of individual 


submissions. Similarly, RG output might have different reviewing 
criteria from that of other documents considered as individual 
submissions. This discussion is ongoing. 


More visibility for RG Internet-Drafts could increase the level of 
interchange between the RG and the rest of the community. 


It would also be helpful to decrease the delay in the publication 
time for IRTF RFCs. Anything that *increased* the publication time 


would probably be counterproductive. 


5. Security Considerations 


There are no security considerations in this document. 
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